Issues were resolved by correcting attributes in the authoritative source (on‑prem Active Directory or the HR/Workday record) and allowing directory synchronization to propagate the changes. Mail‑alias leakage was resolved by removing unwanted values from users' proxyAddresses in the authoritative AD; personal numbers were removed or corrected in Telephones/HomePhone in the authoritative directory so Teams and contact cards no longer exposed them. Job titles (including academic prefixes) were updated in the authoritative directory or HR export; where HR import timing delayed display, administrators noted the HR record as the source of truth. Incorrect reporting lines were fixed by updating the manager attribute in the authoritative source. In environments where Workday authored directory entries and Okta pushed changes to AD, manual AD edits were temporary because the Okta/Workday synchronization overwrote them; affected users were routed to update the Workday record (Workday support) to prevent recurrence. Changes were observed in Entra/Azure AD, Teams, Outlook and contact cards after Azure AD Connect/Entra/Okta sync completed, typically within hours and up to 24–48 hours; in one case a phone number updated in AD became visible in Teams the following day.

Support created the requested Active Directory security groups and provisioned corresponding Access Packages in the Identity Management system. Each new AD group was registered for AWS use and assigned the requested user(s) as members so the roles/entitlements became visible in the target AWS accounts (Dev, Non-Prod, Prod); Group IDs were captured and provided for AWS role mapping. Approvers were configured per request (including handling approver changes when individuals were OOO). Examples of created groups included team- and project-scoped names such as AWSIDSSPerconaCare and a set of AWSConstructor roles (AWSConstructor, AWSConstructorAdministrator, AWSConstructorPowerDeveloper, AWSConstructorDeveloper, AWSConstructorReadOnly), in addition to earlier-created groups for marketing, AI Autonomous, IDSS Simovative, and CPIT MarTech. The combination of AD group creation, Identity Management AccessPackage provisioning, member assignment, approver assignment, and delivery of Group IDs resolved the visibility and entitlement issues in AWS.

Support resolved multiple incidents where Windows devices could not authenticate to corporate wireless or sign in at the Windows lock screen by reconciling AD group state, repairing stale client credentials, and addressing workstation-domain account issues. Recorded corrective actions included: - Restoring or re-creating the AD Wireless/WirelessCPG group and re-adding users; assigning the Wireless group to newly created Windows 11 objects when it had been omitted. - Copying AD group memberships from a reference user and populating missing attributes (Employee ID) to restore expected domain and service access; example groups assigned in one case included Client-VPN-Meraki, CPG-AD-Domainmember, IUG-Intune-App-AdobeCC, WirelessUserAccess-CPG-Corp, and Mac-LocalAdmin-Shortterm. - Restoring domain group membership for relocated or long-absent users who had not been using Okta credentials on-device. - Clearing stale wireless profiles and saved/cached credentials (removing the CP wireless profile) or synchronizing the PC’s cached/local password with the user’s AD password when cached credentials were out of sync (notably correlated with CPG-Net presence at some sites). - Addressing computer-account/trust failures that blocked first-time or relocated-workstation logons; in one record the technician confirmed device identity (serial number) and the user was subsequently able to log in (no further changes were documented). - Resolving BitLocker lockouts by performing a password reset and providing the BitLocker recovery key so the device was unlocked; restoring AD group membership then re-established network access and group-based policies. Several intermittent login failures were recorded as resolving without active remediation, consistent with transient communication issues between the workstation and AD/authentication servers.

Support corrected the authoritative value in Okta by setting the numeric countryCode (906 for Kosovo) in the user's Okta profile and then re-ran the synchronization. After the manual numeric countryCode was applied and the sync executed the user was provisioned into Active Directory and Azure AD successfully.

Support restored the user's long-term administrator entitlement by adding the user to the AD group 'MAC-LocalAdmin-longterm' and to the Mac's longtime-admin local group. The user then used the IU Self Service app on the Mac to activate the long-term admin role; once activated the user regained the ability to install and update applications without repeated admin prompts.

The incidents were resolved by restoring required Active Directory group memberships and correcting an incorrect license assignment where applicable. Affected accounts were added to the Windows 11 provisioning/user group and other required AD groups (examples observed: Win11 Usergroup, Okta MFA Group, CPG-AD-Domainmember, Wireless group, Meraki Client). In one incident the user's Microsoft 365 license was changed from A1 Plus to A5 and the Intranet assignment was set as externally assigned; after these changes the Meraki client and device provisioning completed and Okta sign-in/setup proceeded successfully. Group assignments and memberships were verified after remediation.

The Okta AD Agent in production was upgraded from version 3.16 to 3.19. The update was performed (noted in change control discussions) and post-update verification was conducted by reviewing the agent log files, which showed normal operation after the upgrade. The ticket workflow and approval were recorded in Automation for Jira.

The group was removed from the Azure AD sync scope so it was no longer re-synced from Entra. Administrators reviewed membership, then deleted the group from Okta and Active Directory. Deletion and sync configuration changes were confirmed complete.

Operators located and used the Okta Workday connector/interface to perform an import from Workday into Okta. The import triggered Okta's provisioning workflow which created the AD account and applied group memberships according to the provided reference. The import completion was confirmed and the tickets were closed.